Device Provisioning
Who should read these docs?
Anyone involved in bringing a new product onto the CPP platform: firmware engineers, software engineers, manufacturing engineers, and project managers. Start here to understand the overall model before reading the phase-specific pages.
This guide explains how to provision IoT devices with the certificates they need to securely communicate with the Connected Products Platform (CPP). By the end of this section, you'll understand the complete flow from an unprogrammed device to a fully provisioned device ready for production use.
The Two-Phase Certificate Model
Device provisioning in CPP uses a two-phase certificate model to balance security with operational flexibility:
- Phase 1 - Bootstrap Certificate: Obtained via REST API during manufacturing or initial setup
- Phase 2 - Operational Certificate: Obtained via MQTT Fleet Provisioning at device runtime
This two-phase approach ensures that devices can be securely provisioned at scale while maintaining the ability to rotate certificates throughout the device lifecycle.
Why Two Phases?
The two-phase model addresses several real-world challenges:
- Manufacturing constraints: The device cannot authenticate with the cloud until it has a certificate, so something outside of the firmware running on the device must have a mechanism for providing the first certificate.
- Security isolation: Bootstrap certificates have extremely limited permissions, reducing risk if compromised during manufacturing.
- Certificate rotation: The bootstrap certificate serves as a fallback mechanism when operational certificates have expired and need to be rotated.
Certificate Types
CPP uses two distinct certificate types, each with a specific purpose in the device lifecycle.
Bootstrap Certificate
The bootstrap certificate is a long-lived X.509 certificate obtained during manufacturing via the REST API.
| Property | Description |
|---|---|
| Acquisition | REST API (/management/v1/devices/certificate/csr) |
| Lifespan | Long-lived. Never changes throughout life of device. |
| Purpose | Authenticate device during provisioning; fallback for certificate rotation. |
| Permissions | Limited. Can only be used to request operational certificates. |
| Storage | Must be retained on device permanently. |
The bootstrap certificate cannot be used for normal device operations like updating shadows or publishing asset scan data. It can only be used to request an operational certificate via MQTT Fleet Provisioning.
Operational Certificate
The operational certificate is the primary certificate used for all device-to-cloud communication after provisioning.
| Property | Description |
|---|---|
| Acquisition | MQTT Fleet Provisioning (using bootstrap cert for authentication) |
| Lifespan | 1 year |
| Purpose | All runtime MQTT communication (shadows, asset scans, OTA jobs) |
| Permissions | Full device permissions based on IoT policy. See Normal Device Operation. |
| Storage | Must be stored securely; Must be rotated if/when it expires or when a Job requests the operational cert be rotated. |
When Each Certificate Is Used
Devices must retain both the bootstrap and operational certificates. The bootstrap certificate is essential for certificate rotation scenarios where the operational certificate needs to be replaced.
Complete Flow
The diagram below shows the full interaction across all participants, from tool record registration through to a fully provisioned device connected with its operational certificate.
Firmware Boot Sequence
The decision logic below is what firmware should run on every boot. The details for each path are covered in the pages linked from each node.
See Phase 2 for the provisioning flow, and Certificate Rotation for both rotation paths.